起初，JRockit Mission Control只是JRockit开发团队用来对JRockit JVM进行监控和调试的内部工具集。这些分析工具本身并非为用户而开发，不过在为用户解决了不少高端问题后，顿时威名远扬，同时开发团队意识到，这些工具对用户分析其应用程序是很有帮助的，于是他们将这些分析工具做得更加易用，更具模块性，并作为Java相关工具随JRockit JDK一起发布，这就是后来的JRockit Mission Control。
如今，JRockit Mission Control套件集监控、管理和分析功能于一身，还可以跟踪分析内存泄漏。它能够以非常小的执行开销获取到应用程序的运行时数据，相比之下，大部分其他的分析工具都会使用应用程序严重拖慢应用程序的运行，因而改变了应用程序原有的行为。正如在第5章中提到的，如果分析工具的执行开销过大，那么最终观测到的就不是应用程序真实的行为了，而是应用程序和分析工具共同作用的结果。
由于做性能分析而改变应用程序运行行为的现象可以归为 观察者效应，即观察者的行为改变了被观察者的行为。有时，也称观察者效应为海森堡效应，或统称为海森堡不确定性原理。
在BEA被Oracle收购之前，BEA的性能团队内部层使用不同的性能分析工具。为了使WebLogic服务器上J2EE应用程序的基准测试更加精确，性能团队一直在寻找执行开销较低的分析工具，他们筛选出几种不同的分析工具，并通过基准测试计算了性能分析工具的执行开销，结果显示Mission Control的执行开销是0.5%，测试结果中排名第二的是另一款比较著名的Java分析器，但其执行开销却高达93.8%。
译者注，作为扩展内容，关于海森堡不确定性原理，推荐阅读《上帝掷骰子吗-量子物理史话》。
一般来说，不同的工具有不同的适用场景，JRockit Mission Control所收集到的数据只是在统计学意义上，准确展示出当前JRockit JVM当前的运行状态，虽然并非完全准确，但也可以为解决各种问题提供必要的信息了。这种分析方式即所谓的 采样分析（sampling-based profiling），适用于周期性记录目标的状态。JRockit Mission Control套件中最常用的是基于时间的采样（time-based sampling）和基于状态改变子集的采样（sampling based on a subset of state changes）。作为一个巨大的状态机，JVM可以以较低的开销提供大量的采样信息和事件信息供分析人员使用。此外，使用采样分析的另一个好处是可以很容易的评估分析本身的执行开销。
例如，使用JRockit Flight Recorder工具排查热点方法列表可以很容易的确定应用程序主要把时间都花在了哪里。通过对代码分析线程提供的数据进行统计，可以给出热点方法列表，却无法给出每个方法的调用信息或执行该方法的精确时间信息。
除了采样分析外，JRockit Mission Control还可以执行准确分析，但启用准确分析可能会有较大的执行开销。例如，使用JRockit Management Console连接到正在运行的应用程序（但注意不要在生产环境这么干），对系统中的每个方法启用准确计时和调用计数器，不过执行准确分析会产生额外的运行时开销。对系统的中的每个方法启用准确分析需要JVM生成并执行大量额外的分析代码，这不仅会影响系统性能，而且也很难确定分析代码自身对系统产生了哪些影响。JRockit中有一部分代码是用Java写的，如果对所有内存分配和锁操作代码都做分析的话，应用程序肯定就没法正常工作了。如果是为了确定当前最需要对应用程序的哪部分做优化，还是使用采样分析更合适。
人们可能会说，虽然准确分析带来了不小的开销，但却可以更好的完成分析任务。例如，在给定准确数据的情况下，可以测量出系统中所有方法的执行时间，将方法的调用次数乘以执行时间，再排个序，不就可以确定出优化目标了么？
但事实上，在一个足够复杂的系统中，上述测量所得到的数据未必是真实有效的。在启用准确采样的前提下，系统中关键路径上方法的执行开销会迅速增大，并导致系统的整体性能下降。进一步讲，对系统中每个方法都做准确详细的分析有可能会改变应用程序原有的行为，导致无法得到准确的测量结果。
就JRockit Mission Control来说，Management Console工具算是个特例，因为使用它来获取方法的准确执行时间和调用次数时，难以评估其自身的执行开销。统计方法调用次数的代码一般会被放置在方法的入口点和出口点，因此测量结果的失真程度正比于方法的执行频率，反比于方法的执行时间。如果方法被频繁调用，测量的额外开销就是显著的影响因素；如果目标方法已经执行了很长时间了，额外开销也就显得无足轻重了。在多线程场景下，Management Console的准确式分析所导致的不确定性会更大。
JRockit Mission Control的适用范围很广，在外面，它往往被作为一款功能强大的分析工具使用。
有些用户使用JRockit Mission Control来跟踪应用程序的问题，这也是Oracle支持服务的主要工作内容。此外，在开发阶段，使用JRockit Mission Control还有助于发现应用程序潜在的性能问题和bug。
当然，还有一些像作者一样的Geek，他们综合运用JRockit Mission Control和基准测试，结合对JVM和应用程序的调优，竭力找出JRockit JVM的所有性能。
下面是一些JRockit Mission Control的典型适用场景：
Reference对象。"乔治！！为毛你的股票报价缓存中有一个巨大无比的HashMap对象啊！！光它自己就占了96%的堆内存啊！！而且大小还在涨啊！！照这么运行下去，俩小时之内肯定宕机啊！！之前不得不每礼拜重启两次应用程序就因为你啊！！看什么看！！你们写的不咋地！！"